Conventional solutions for virtualization technology provide numerous capabilities to efficiently deliver applications and desktops by packaging them as virtual machines. Virtualization is a technology that provides a software based abstraction to a physical hardware based computer. The abstraction layer decouples the physical hardware components—CPU, memory, and disk from the Operating System (OS) and thus allows many instances of an OS to be run side-by-side as virtual machines (VMs) in complete isolation to one another. The OS within each virtual machine sees a complete, consistent and normalized set of hardware regardless of the actual physical hardware underneath the software based abstraction. Virtual machines are encapsulated as files (also referred to as images) making it possible to save, replay, edit, copy, cut, and paste the virtual machine like any other file on a file-system. This ability is fundamental to enabling better manageability and more flexible and quick administration compared to physical virtual machines.
Those benefits notwithstanding, conventional VMs suffer from several performance related weaknesses that arise out of the way the VM interfaces with the storage sub-system(s) that stores the VM images or files. The storage sub-system(s) can include one or more server racks with each rack including networking gear (e.g., routers, switches, etc.), server computers, and locally attached storage (e.g., a hard disk drive—HDD) for each server. Furthermore, the storage sub-system(s) can be in communication with a storage network such as a Storage Area Network (SAN) or Network Attached Storage (NAS). The servicing of I/O from the VMs through those storage sub-system(s) introduces latencies (e.g., due to write operations) and redundancies that can create I/O bottlenecks and can reduce system performance. The aforementioned performance weaknesses include but are not limited to the following examples.
First, every read operation or write operation performed by every single VM (and there can be hundreds if not thousands of VMs performing such operations concurrently) is serviced in a queue by the storage system. This creates a single point of contention that results in below-par performance.
Second, there are numerous latencies that develop as input/output (IO) is queued at various points in an IO stack from a VM hypervisor to the storage system. Examples of latencies include but are not limited to: (a) when an application residing inside a Guest OS issues an IO, that IO gets queued to the Guest OS's Virtual Adapter driver; (b) the Virtual Adapter driver then passes the IO to a LSI Logic/BusLogic emulator; (c) the LSI Logic/BusLogic emulator queues the IO to a VMkernel's Virtual SCSI layer, and depending on the configuration, IOs are passed directly to the SCSI layer or are passed thru a Virtual Machine File System (VMFS) file system before the IO gets to the SCSI layer; (d) regardless of the path followed in (c) above, ultimately all IOs will end up at the SCSI layer; and (e) IOs are then sent to a Host Bus Adapter driver queue. From then on, IOs hit a disk array write cache and finally a back-end disk. Each example in (a)-(e) above introduces various degrees of latency.
Third, Least Recently Used (LRU)/Least Frequently Used (LFU)/Adaptive Replacement (ARC) cache replacement techniques all ultimately rely on building a frequency histogram of block storage access to determine a value for keeping or replacing a block from cache memory. Therefore, storage systems that rely on these cache management techniques will not be effective when servicing virtualization workloads especially Desktop VMs as the working set is too diverse for these techniques to manage cache consolidation and not cause cache fragmentation.
Fourth, in a virtualization environment, there typically exist multiple hierarchical caches in different subsystems—i.e. the Guest OS, the VM Hypervisor and a Storage Area Network (SAN)/Network Attached Storage (NAS) storage layer. As all the caches are independent of each other and unaware of each other, each cache implements the same cache replacement policies (e.g., algorithms) and thus all the caches end up all caching the same data within each independent cache. This results in an inefficient usage of the cache as cache capacity is lost to storing the same block multiple times. This is referred to as the cache inclusiveness problem and cannot be overcome without the use of external mechanisms to co-ordinate the contents of the multiple hierarchical caches in different subsystems.
Finally, SAN/NAS based storage systems that are under load ultimately will always be at a disadvantage to service virtualization workloads as they will need to service every IO operation from disk as the cache will be overwhelmed and fragment in the face of a large and diverse working set and because of diminished capacity within the caches due to the aforementioned cache inclusiveness problem.
Reference is now made to FIG. 1 where a conventional configuration 100 for a virtual machine (VM) includes a one or more users 140 who operate one or more thin clients 145 (e.g., terminals, desktop, tablet, or laptop PC's, devices connected via a KVM, a touch screen device, etc.) that are in communications 149 with a network 150 (e.g., LAN or WAN). Each user 140 generates a remote session symbolized as a virtual machines (VM) 135 (e.g., VM1, VM2, . . . , VMn). Each VM 135 comprises an instantiation of a virtual machine running on a computer program denoted as VM Hypervisor 130 (e.g., a conventional VM hypervisor program such as VMware® or other suitable virtual machine program). Here, conventional VM Hypervisor 130 is in communication with a system for processing, data storage, and data communications, such as a server rack 175 that includes a one or more servers 102a, 102b, 102c, . . . , 102n, and network gear 101 (e.g., switches, routers, etc.). Servers 102 can be a blade server or X86 based server, for example. Furthermore, each server 102 in rack 175 can include a CPU 103 (e.g., Intel X86 or AMD processors), memory 105 (e.g., DRAM or the like), and a storage device 107 (e.g., locally attached storage such as a HDD, SSD, or equivalent devices). Constituents of the rack 175 and VM Hypervisor 130 are in communications 131 with a storage network 110 (e.g., LAN, WAN, Wireless) configured to communicate 133 with a storage system 120 (e.g., an EMC or a NetApp storage system) comprised of one or more storage devices 125 (e.g., HDD's, RAID systems, cloud storage, etc.).
Each storage device 125 can include data 127a comprised of an OS Image, OS Runtime, Application Image, and Application Runtime, each of which is associated with the various VMs 135. Data 127a may be duplicated in one or more of the storage devices 107 in server rack 175 as denoted by duplicate data 127b. As described above in regards caches, it is undesirable to duplicate data, particularly if there is no advantage to having duplicate storage of the same data. Storage system 120 is particularly well suited to running read intensive operations such as web page browsing, for storage of files associated with programs such as MS Office (e.g., MS Word, Excel, and PowerPoint files), and for database applications that are read intensive, for example. However, programs or activity by users 140 or others that result in intensive write operations can create I/O latencies among components of the server rack 175, storage system 120, and storage network 110. I/O latencies can be caused by sequentially bound I/O operations to/from various storage elements in the rack 175 and/or storage system 120. For example, for write intensive operations to those storage elements, the write operations can be sequentially bound, regardless of whether the write data is the same or different, such that N write operations requires N sequentially executed write operations (e.g., one after another). The above performance weakness examples are a non-exhaustive list and there are other performance weaknesses in conventional virtualization technology.
There are continuing efforts to reduce data I/O latencies, data redundancy, and to improve processes, cache techniques, software, data structures, hardware, and systems for VM technology.
Although the above-described drawings depict various examples of the present application, the application is not limited by the depicted examples. It is to be understood that, in the drawings, like reference numerals designate like structural elements. Also, it is understood that the drawings are not necessarily to scale.